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DETAILED ACTION 

1. Claims 1-44 are pending. Applicant has amended claims 1,21 and 41. 

Continued Examination Under 37 CFR 1.114 

2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1 .17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on 4/21/2008 has been entered. 

Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. Claims 1, 4-13, 15, 17-21, 24-33, 35, 37-41, 43 and 44 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Bhattacharya (Design Notes on Asynchronous I/O (aio) 
for Linux) in view of Chauvel et al. (U.S. 2002/0194441 Al). 



As to claim 1 , Bhattacharya teaches in a computer system, a method for retrieving events 
from an event port, the method comprising: 
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- receiving from a computer software application, a request to retrieve a specified number 
of events from an event port to which completed events are posted by one or more event 
sources (completion queues, there are api's ... with that queue; page 8, third paragraph, 
and 'Ability to reap many events together . . . than just a single event"; page 8, last 
paragraph and 'Ability to wait for at least a specified number ... to complete"; page 9, 
section 'Enable flexible grouping of operations', and completion port style; page 13, 
section 2.7), 

- determining whether the specified number of events is available at the event port (A 
natural extension ... or go back to sleep; page 12, section 2.6.2 and Retrieve completion 
event ... to arrive; page 14, section 3.1), 

if the specified number of events is available at the event port, retrieving the specified 
number of events from the event port and returning the retrieved events to the requesting 
computer software application (A natural extension ... or go back to sleep; page 12, 
section 2.6.2 and When the operation complete . . . ring buffer; page 1 8, section 4.2.2), 
and 

if fewer events than the specified number of events are available at the event port, placing 
the request in a request queue with requests to be processed at a later time (A natural 
extension ... or go back to sleep; page 12, section 2.6.2, and If no events are present, then 
wait for up to the timeout for at least one event to arrive; page 14, section 3.1 and wait 
queue; page 15, section 4.1.1 and page 17, section 4.2.1) and ordering the request queue 
based on priorities of the requests in the request queue (priority; pages 6-7, section 2.4 
and page 10, section 5). 
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Bhattacharya does not explicitly teach changing the priorities of the requests in the 
request queue based on the number of events available at the event port, wherein the changing is 
further based on a specified number of events to be retrieved as part of at least one request 
received in response to at least one indication about the number of events available at the event 
port. 

However, Chauvel teaches each access request in the request stack has a priority 
associated with it (page 8, paragraph [0060]), and changing the priority of the request in the 
request stack based on the status of how much data remains in the queue by assigning different 
priority value to the request(page 9, paragraph [0067]). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to apply the teaching of Chauvel to the system of Bhattacharya because Chauvel 
teaches changing the priority of pending requests based on the status of available of data in the 
queue would reducing access latency (page 1, paragraph [0004]), thus, the performance of the 
Bhattacharya' s system would increased. 

As to claim 4, Bhattacharya does not teach wherein the specified number of events to be 
retrieved from the event port indicates a priority of the request. However, Bhattacharya teaches 
the priority of the request is provided by the application (pages 6-7, section 2.4) and the number 
of events to be retrieved is also provided by the application (page 12, section 2.6.2). It would 
have been obvious to one of ordinary skill in the art that the application can be implemented to 
have the number of events to be retrieved indicates the priority of the request. 
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As to claim 5, Bhattacharya does not explicitly teach wherein a priority of a request is 
inversely proportional to the specified number of events. See discussion of claim 4 above for the 
same reason. 

As to claim 6, Bhattacharya teaches wherein the request queue contains requests 
generated by one or more computer software application threads (an application can issue a wait 
on a given queue to be notified of a completion event for any request associated with that queue; 
page 8, third paragraph and wait queue; page 15, section 4.1.1 and page 17, section 4.2.1). 

As to claim 7, Bhattacharya teaches wherein the request queue contains requests 
generated by one or more computer software application processes (an application can issue a 
wait on a given queue to be notified of a completion event for any request associated with that 
queue; page 8, third paragraph and wait queue; page 15, section 4.1.1 and page 17, section 4.2.1). 

As to claim 8, Bhattacharya teaches wherein the number of events to be retrieved from 
the event port is specified by the computer software application (page 12, section 2.6.2). 

As to claim 9, Bhattacharya does not explicitly teach wherein the number of events to be 
retrieved from the event port is specified by the computer software application based on user 
input. However, Bhattacharya teaches implement at-least-N semantics purely in user space (page 
12, section 2.6.2). It would have been obvious to one of ordinary skill in the art at the time the 
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invention was made to have the number of events to retrieve is specified by the user, so the user 
can have control over the system. 

As to claim 10, Bhattacharya teaches 

if fewer events than the specified number of events are available at the event port, 
determining whether there are any requests in the request queue that can be satisfied by 
the available number of events at the event port (there are also ... for this operation; page 
10, section 3, and wakeup only waiter whose "N-value" matches or exceeds the number 
of events available; page 12, section 2.6.2), and 
- if there are requests in the request queue that can be satisfied, retrieving the specified 
number of events from the event port for one or more such requests and returning the 
retrieved events to the requesting computer software application (and then have them try 
to pick up its N events; page 12, section 2.6.2). 

As to claim 11, Bhattacharya teaches wherein the request has an associated timeout prior 
to which the request must be satisfied (Wait up to the timeout for the i/o described by the specific 
iocb to complete; page 14, third paragraph). 

As to claim 12, Bhattacharya teaches if a timeout occurs for a request while the request is 
in the request queue, retrieving all the available events at the event port a the time of timeout, 
and returning the request to the computer software application with the retrieved events (The 



Application/Control Number: 10/789,523 
Art Unit: 2194 



Page 7 



DASF api support ... in case of a timeout; page 9, section 2 'Enable flexible grouping of 
operations'). 

As to claim 13, Bhattacharya does not explicitly teach returning an empty request to the 
requesting software application if the request cannot be satisfied. However, Bhattacharya teaches 
wait up to the timeout for the i/o to complete (page 14, third paragraph). It would have been 
obvious to one of ordinary skill in the art that an empty response would be returned if the i/o has 
not been completed by the time the timeout is up. 

As to claim 15, see rejection of claim 13 above. Bhattacharya further teaches the timeout 
may occur before the completion event arrived to the completion queue. It would have been 
obvious to one of ordinary skill in the art at the time the invention was made to modify the 
teaching of Bhattacharya to have the error message return if the request contains an invalid event 
port identifier, an event or a list of events list cannot be delivered, a timeout argument is out of 
range, and a timeout interval expires before an expected number of events has been posted to the 
event port. 

As to claim 17, Bhattacharya does not explicitly teach if the specified number of events is 
zero, identifying the number of available events at the event port, and informing the requesting 
computer software application of how many events are available at the event port. However, 
Bhattacharya teaches if no events are present, then wait for up to the timeout for at least one 
event to arrive (page 14, section 3.1), and also other waiter is waited on the same event (page 10, 
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second paragraph). It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the system of Bhattacharya to let the application know how many 
events are queued in the completion queue, so they can aware as whether the queue is empty or 
full to have other option, such as cancel the operation (page 14, section 3.1). 

As to claim 18, Bhattacharya teaches wherein the events are asynchronous events (Option 
to wait for notification of aio events; page 3, second paragraph). 

As to claim 19, Bhattachary teaches wherein the events are transaction events (wait for 
all the submitted events to complete; page 13, second paragraph). 

As to claim 20, Bhattachary teaches wherein the event sources include one or more of: 
input devices, output devices, timers, signals, file updates, applications, system libraries, and 
drivers (page 2, sections 1.1 and 1.2). 

As to claim 21, it is the same as the method claim of claim 1 except it is a computer 
product claim, and is rejected under the same ground of rejection. 

As to claims 24-33, see rejection of claims 4-13 above. 



As to claim 35, see rejection of claim 15 above. 
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As to claim 37, see rejection of claim 17 above. 

As to claims 38-40, see rejections of claims 18-20 above. 

As to claim 41, see rejections of claims 1 and 6 above. Bhattacharya further teaches an 
event queue for receiving transaction events generated by one or more event sources, the event 
queue being accessible through an event port (completion queues, api; page 8, third paragraph). 

As to claim 43, see rejection of claim 4 above. 

As to claim 44, see rejection of claim 1 1 above. 

5. Claims 2, 3, 22, 23, and 42 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Bhattacharya (Design Notes on Asynchronous I/O (aio) for Linux) in view of Chauvel 
et al. (U.S. 2002/0194441 Al) further in view of Benhase et al. (U.S. 6,745,262 Bl). 

As to claim 2, Bhattacharya does not explicitly teach wherein ordering comprises placing 
requests with a higher priority ahead of requests with lower priority in the request queue. 
However, Benhase teaches wherein ordering comprises placing requests with a higher priority 
ahead of requests with lower priority in the request queue (see Fig. 2). It would have been 
obvious to one of ordinary skill in the art at the time the invention was made to apply the 
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teaching of Benhase to the system of Bhattacharay because Benhase teaches a method and data 
structure for queuing requests capable of having different priority levels (col. 1, lines 8-10). 

As to claim 3, Bhattacharya does not explicitly teach wherein ordering comprises placing 
two or more requests with a same priority in a stack, and placing the stack in the request queue 
based on the priority of the requests in the stack. However, Benhase teaches ordering comprises 
placing two or more requests with a same priority in a stack, and placing the stack in the request 
queue based on the priority of the requests in the stack (abstract). It would have been obvious to 
one of ordinary skill in the art at the time the invention was made to apply the teaching of 
Benhase to the system of Bhattacharya because Benhase teaches a method and a data structure 
for queuing requests capable of having different priority levels (col. 1, lines 8-10), and this will 
improve the performance of Bhattacharya's system by avoid managing multiple priority queues 
by the system (col. 2, lines 38-40). 

As to claims 22-23, see rejections of claims 2-3 above. 

As to claim 42, see rejection of claim 3 above. 

6. Claims 14, 16, 34 and 36 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Bhattacharya (Design Notes on Asynchronous I/O (aio) for Linux) in view of Chauvel 
et al. (U.S. 2002/0194441 Al) further in view of Lucovsky et a. (U.S. 6,223,207 Bl). 
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As to claim 14, Bhattacharya does not teach wherein returning comprises returning the 
empty request together with an error indicating the cause for why the request cannot be satisfied. 
However, Lucovsky teaches for each request that related to the completion port, there is error 
handling if there are any type of error (col. 12, lines 44-64 and col. 13, line 46-55). It would have 
been obvious to one of ordinary skill in the art at the time the invention was made to apply the 
modified the teaching of Lucovsky to the system of Bhattacharya because Lucovsky teaches a 
method to let the application users know the reason of the error, so the user can have option to 
handle the errors that raise during the execution of the system. 

As to claim 16, Bhattacharya teaches wherein returning the retrieved events to the 
requesting computer software application comprises returning one or more of one or more 
detected events (then have them try to pick up its N events; page 12, section 2.6.2). Bhattacharya 
does not teach one or more event source identifiers where the detected events were generated, 
one or more objects specific to an event source, and one or more user defined values. However, 
Lucovsky teaches the completion packet contains the number of bytes read/written, error 
indication, the context associated with the particular I/O operation, the context associated with 
the particular file handler (col. 13, line 64 - col. 14, line 1). It would have been obvious to one of 
ordinary skill in the art at the time the invention was made to apply and modify the teaching of 
Lucovsky to the system of Bhattacharya because Lucovsky teaches a method to return additional 
data to application. 



As to claim 34, see rejection of claim 14 above. 
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As to claim 36, see rejection of claim 16 above. 

Response to Arguments 

7. Applicant's arguments with respect to claims 1-44 have been considered but are moot in 
view of the new ground(s) of rejection. 

Conclusion 

8. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. See PTO 892. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to DIEM K. CAO whose telephone number is (571)272-3760. The 
examiner can normally be reached on Monday - Friday, 7:30AM - 3:00PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Meng-Ai An can be reached on (571) 272-3756. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

DC 

June 17, 2008 



/Diem K Cao/ 

Examiner of Art Unit 2194 



